<?php
/**
 * <https://y.st./>
 * Copyright © 2017 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'A sleepless night',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2017/09/29.jpg" alt="Dainty, white flowers" class="framed-centred-image" width="800" height="480"/>
<section id="general">
	<h2>General news</h2>
	<p>
		I didn&apos;t sleep well last night.
		It seemed like I didn&apos;t sleep at all, but I&apos;m certain I must&apos;ve, or I&apos;d be much more tired than I am now.
		I kept getting up though, both feeling dehydrated and needing to urinate.
		I don&apos;t know what was going on, but hopefully I don&apos;t have the problem tonight as well.
	</p>
</section>
<section id="university">
	<h2>University life</h2>
	<p>
		<del>Between the fact that my usual citation-generating site was down and the fact that I slept in late because I didn&apos;t get enough sleep last night, I didn&apos;t get the discussion post submitted that I&apos;d wanted to complete today.</del>
		aside from the citations though, I did get it written up after completing the reading material in that course.
		<del>I should be able to get it submitted after work tonight, a bit after midnight.</del>
		<ins>Scratch that.
		Just before I needed to head out to work, the citation generator loaded, so I was able to submit my post after all:</ins>
	</p>
	<blockquote>
		<h3>Cascading</h3>
		<p>
			Cascading is the property of $a[CSS] in which multiple selectors can apply rules to the same element, and the unrelated style rules can be applied together ($a[W3C], 2012).
			For example, if one selector selects all paragraph elements and sets their font size to <code>1.5em</code>, another selector could select all paragraphs and set their colour to <code>#111</code>.
			The first selector doesn&apos;t prevent a second selector from changing properties on the same element, nor does the second selector nullify the first.
			If multiple selectors change the same property on an element, the highest-priority selector will be applied last, overwriting the previously-set value.
			Likewise, selectors might not select exactly the same set of elements, but instead overlap in what they select.
			Elements covered by both selectors will likewise be subject to the rules of cascading.
			To understand the order in which selectors will be applied, it&apos;s important to know about the different classes of style sheets.
			User agent style sheets are those built into the client software, and are client-specific.
			User style sheets are those set by the user in their user agent, and are client-instance-specific.
			Author style sheets are those built into or referenced by a given webpage, and are webpage-specific.
			The order in which styles are applied is as follows ($a[W3C], 2012):
		</p>
		<ol start="0">
			<li>User agent style sheets</li>
			<li>Normal declarations in user style sheets</li>
			<li>Normal declarations in author style sheets</li>
			<li>Important declarations in author style sheets</li>
			<li>Important declarations in user style sheets</li>
		</ol>
		<p>
			Unimportant declarations in user style sheets will be applies before (so with less priority than) author style sheets, whether those author styles are important or not.
			Important user style sheets will be applied after (so with greater priority than) author style sheets, whether important or not.
			Important style rules are marked in the $a[CSS] code with the <code>!important</code>flag ($a[W3C], 2012).
			When styles are of the same importance, they are applied least-specific to most-specific ($a[W3C], 2012).
			If the style has no selector because it was used from a <code>style</code> attribute of an element (which should be avoided), it has top priority and will be applied last.
			If the <code>#</code> operator was used to select an attribute by its <code>id</code> attribute, it takes priority after (and will thus be applied just before) $a[CSS] in the <code>style</code> attribute.
			After that (or rather, before), selectors using classes will be applied, with selectors referencing more classes taking higher priority and being applied last.
			Before that, selectors selecting elements by tag name will be applied.
			And first, at the lowest priority, the <code>*</code> selector will be applied.
			Finally, if style rules have the same importance and same specificity, they will be applied in the order in which they appear in the file ($a[W3C], 2012).
			That is, the later the rule is in the file, the more it will override and the more priority it has.
		</p>
		<h3>Things you can do with $a[CSS] that would be difficult or impossible without it</h3>
		<p>
			It is my <strong>*strong*</strong> belief that using inline $a[CSS] within the <code>style</code> attribute of an element provides no advantages over the old, deprecated way of styling pages.
			The strength of $a[CSS] comes into play only when $a[CSS] is instead used through the <code>&lt;style/&gt;</code> element as embedded styles or <code>&lt;link/&gt;</code> element as external styles; my preferred choice being the latter.
			There are many new styling options that exist in the $a[CSS] language that were never available in $a[HTML] alone, but that&apos;s only because $a[CSS] was chosen as the future of styling.
			Those same options could have been added to $a[HTML] and $a[XHTML], had $a[CSS] not been invented, so discussing the new styling options would entirely miss the point as far as what $a[CSS] is actually good for.
		</p>
		<h4>Separate the structure files of your pages from your style files, and reuse the styles with multiple pages</h4>
		<p>
			Cascading style sheets allow a separation of document files from their styling aspects, at least if external style sheet files are used.
			The construction of pages on my website is fully automated, so when I make a change in the code, every relevant page is updated.
			However, all updated pages need to be uploaded to the server, which takes a while.
			The fewer files that have been updated, the faster the upload will finish.
			Because of the automation, external stylesheets don&apos;t save me time in development, but they do save me a lot of time in uploading.
			With external $a[CSS], you can update only your one (or few) external style sheet and the appearance of every page on your website will be updated too, as long as those pages reference that style sheet with the <code>&lt;link/&gt;</code> tag.
		</p>
		<h4>Specify the same style for multiple elements</h4>
		<p>
			Without $a[CSS], if we had a way to style an element, we&apos;d need to specify that style on each instance of the element that we wanted styled.
			For example, if we wanted all paragraphs on the page to use a monospace font so our page looked like a command line interface, we&apos;d need to specify that information in the opening tag of <strong>*each and every paragraph*</strong>.
			That&apos;s enough of a pain as it is, but what if we later wanted to use DejaVu Serif?
			We&apos;d need to update every paragraph on the page individually, which would be rather tiresome and a waste of development time.
			With $a[CSS], whether used from within a <code>&lt;style/&gt;</code> element or linked to with a <code>&lt;link/&gt;</code> element, allows us to specify in one place that all paragraphs should be given a certain appearance.
			If we later want to change what that appearance is, we can do so in one place instead of several.
		</p>
		<h4>Specify different styles for different mediums</h4>
		<p>
			Different mediums have different limitations to adhere to.
			For example, <a href="https://y.st./">my own website</a> used a black background with white text.
			It looks very nice on the screen and provides plenty of contrast, but could be hard on your ink bill if you tried to print one of my pages.
			With $a[CSS], it&apos;s possible to specify a different style sheet for each type of rendering medium.
			When I have time, I should set up a separate style sheet for printers that used black text on a white background.
		</p>
		<h4>Achieve smaller file sizes</h4>
		<p>
			Using $a[XHTML]/$a[HTML] alone (or using inline $a[CSS]), style information has to be repeated as we discussed.
			That results in a lot of extra bytes added to every file, and those files need to be both stored on disk and sent across the network as clients request them.
			Using embedded $a[CSS], most style rules can be condensed so they take up less space and require less network transfer for clients to download.
			Using external $a[CSS] instead, the total size of your website&apos;s files will be drastically reduced as well.
			The bigger your website, the bigger the disk space savings.
			Web browsers usually cache files when they can as well, so the client won&apos;t need to download the same style rules repeatedly, as they would with plain $a[HTML] styling, inline $a[CSS], or embedded $a[CSS].
			Using external style sheets, the pages of your website will load faster and (on metered connections) cost your clients less money.
		</p>
		<h4>Use semantic markup</h4>
		<p>
			Without $a[CSS], developers often needed to rely on hacky tricks that involved misusing elements.
			For example, non-tabular data might be placed in a table just so the developer could get the information to display in the desired way.
			This led to accessibility issues, as user agents depend on elements to represent what they were designed to represent.
			For example, a screen reader would read a table differently than it would a paragraph, so placing the bulk of a website within a table interfered with screen readers&apos; ability to convey the meaning of a website to the blind users that use them.
			With $a[CSS], presentation and purpose are separated, so tables can just be tables, while non-tabular data can still be arranged in a grid-like way without even needing any <code>&lt;table/&gt;</code> tags.
		</p>
		<h3>Other passing thoughts on the reading material</h3>
		<p>
			The reading material this week claims that the Ariel font is ubiquitous, and is probably available on all systems.
			This is far from true.
			It&apos;s a Microsoft font, so it&apos;s available on Windows, the most popular operating system.
			It&apos;s probably also available on OS X, the next runner up.
			However, most operating systems that aren&apos;t at least partially freely-licensed don&apos;t tend to survive like these two operating systems.
			What this means is that most still-in-use operating systems make heavy use of freely-licensed code and resources.
			The Arial font isn&apos;t likely to be found on any Linux system, and Linux systems make up the majority of systems available today.
			Likewise, Arial isn&apos;t likely to be found on a $a[BSD] system, which again, there are several of.
			Arial is a common font to be found on one&apos;s computer because most people use Windows or OS X, but to claim that the font is ubiquitous is highly misleading and to claim that the font is probably available on all systems is an outright lie.
			It&apos;s not available on all systems; it&apos;s available on two common systems, and not available much anywhere else.
			I&apos;m not saying not to use the font in your design, depending on your audience.
			However, don&apos;t assume that everyone has that font, or any other.
			No font is ubiquitous for the time being, and no font likely will be ubiquitous in the near future.
			Proprietary systems like to push their proprietary fonts, so they don&apos;t ship with free fonts.
			Proprietary systems don&apos;t like compatibility with nonfree systems, as they try to use that lack of compatibility as a reason for users to avoid the free system, even though it&apos;s the proprietary system causing the problem.
			(This font issue is only a small compatibility issue compared to most of what proprietary systems try to be incompatible with.)
			Free systems on the other hand don&apos;t use proprietary fonts because of licensing issues.
			Microsoft doesn&apos;t <strong>*allow*</strong> other systems to ship with Microsoft-licensed fonts, as that would provide the compatibility that Microsoft seeks to avoid.
			Always specify one of the five generic font families as a fallback: <code>serif</code>, <code>sans-serif</code>, <code>monospace</code>, <code>cursive</code>, or <code>fantasy</code>.
			The reading also mentioned several other common fonts as being installed across most systems, but I recognised several as being other Microsoft fonts, which again, are pretty much available on only two of the several operating systems out there.
			Almost certainly, none of the listed fonts are available outside of Windows and OS X, which again, means you should use one of the five generic fallback fonts in the right-most position in the font stack in case the font you want displayed isn&apos;t available to your readers.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				World Wide Web Consortium. (2012, October 7). Importance. Retrieved from <a href="https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#Importance"><code>https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#Importance</code></a>
			</p>
			<p>
				World Wide Web Consortium. (2012, October 7). Normal and important declarations. Retrieved from <a href="https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#Normal_and_important_declarations"><code>https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#Normal_and_important_declarations</code></a>
			</p>
			<p>
				World Wide Web Consortium. (2012, October 7). Source order. Retrieved from <a href="https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#Source_order"><code>https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#Source_order</code></a>
			</p>
			<p>
				World Wide Web Consortium. (2012, October 7). Specificity. Retrieved from <a href="https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#Specificity"><code>https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#Specificity</code></a>
			</p>
			<p>
				World Wide Web Consortium. (2012, October 7). The cascade. Retrieved from <a href="https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#The_cascade"><code>https://www.w3.org/community/webed/wiki/Inheritance_and_cascade#The_cascade</code></a>
			</p>
		</div>
	</blockquote>
</section>
END
);
